In a conventional data-processing system, such as a computer and/or a computer network, one or more processors may communicate with input/output (I/O) devices over one or more buses. The I/O devices may be coupled to the processors through an I/O interface such as an I/O bridge, which can manage the transfer of information between a peripheral bus connected to the I/O devices and a shared bus connected to the processors. Additionally, the I/O interface may manage the transfer of information between system memory and the I/O devices or the system memory and the processors.
An I/O interface can also be utilized to transfer information between I/O devices and main storage components of a host processor. An I/O channel, for example, may connect the host directly to a mass storage device (e.g., disk or tape drive). In the case of a mainframe host processor, the channel is usually coupled to one or more device controllers. Each device controller can in turn be connected to a plurality of mass storage devices.
One example of an I/O interface that has become widely utilized in the data processing and computer arts is the so-called “Fibre Channel.” In general, features of both channels and networks have been incorporated into a network standard known as “Fibre Channel,” which has been defined by American National Standards Institute (ANSI) specifications, such as X3.230 (1994). Fibre Channel systems attempt to combine the speed and reliability of channels with the flexibility and connectivity of networks.
In general, data in a Fibre Channel network can be transported in packets, which may be two kilobytes or smaller. These packets of data can be referred to as “frames.” “Sequences” include one or more frames. Frames in a sequence are generally assembled at the receiving device in a predetermined order before the sequence can be considered complete.
Fibre Channel is a campus-wide interconnection standard that is designed primarily to interconnect peripherals, mass storage systems such as redundant arrays of inexpensive disks (RAID), imaging and archiving systems, mainframes, engineering workstations, and other high-speed devices. Often seen as the successor to the Small Computer Serial Interface (SCSI) standard, Fibre Channel is a high-speed channel that typically uses fiber optics to interconnect computing devices in a relatively local environment, such as a laboratory or a campus. Thus, the Fibre Channel focuses more on providing bandwidth between devices than a completely flexible network. Fibre Channel is a switched technology.
The Fibre Channel interface dedicates circuits for transferring data while allowing other devices to access the channel when it is free. The Fibre Channel interface supports variable length transmissions; it can transmit large blocks of data without dividing the blocks into smaller packets. The speed of Fibre Channel is in the range of 133 Mbit/sec-1062 Mbit/sec. While multimode optical fiber is used most often, single mode optical fiber, coaxial cable, and shielded twisted pair wire are also occasionally used in practice. An example of a Fibre Channel method and system is disclosed in U.S. Pat. No. 6,721,320, which issued on Apr. 13, 2004 to Hoglund et al and is assigned to LSI Logic Corporation based in Milpitas, Calif. U.S. Pat. No. 6,721,320 is incorporated herein by reference.
Another well-known I/O interface is Serial Attached SCSI (SAS). SAS incorporates feature of Small Computer System Interface (SCSI), also known as “skuzzy”, which is a bus protocol that allows various internal and external devices to be connected to personal computers, workstations, servers, and/or other data-processing systems. SAS is a is a point-to-point architecture, distinct from parallel technologies in which devices are connected utilizing shared-access topologies, such as a Fibre Channel arbitrated loop of the SCSI bus. As such, a point-to-point architecture establishes a link directly from the controller to a disk drive or through an expander-switching matrix. In shared-access topologies, only two devices can communicate at once. As well, as throughput needs increase, the shared-access medium can become a bottleneck and slow down communication. Shared access topologies also are typically more complex and have arbitration schemes that are more time consuming than point-to-point architectures.
When communicating between a user mode application in a modem operating system (OS) and a storage controller, applications typically rely upon I/O Control (IOCTL) requests. The IOCTL requests have very specific formatting requirements that must be reproduced with each application, adding a significant amount of effort and time to the development of a new application. Such applications must discover the hardware contents of the computer, including storage controllers and attached devices, and must utilize this information. This process is often requested for each project, and the implementation can be time-consuming and error prone.
Most applications that perform IOCTL requests and/or hardware scans use a similar method, but the continued reproduction of such operations leads to slight variations in the process as different projects use different baseline versions of code. In addition, as the code is refined, many projects are not updated with the fixed code, which can lead to the need to repeat debugging efforts.
Current solutions to such problems involve reproducing the device scan and IOCTL requests from one application to another. This is the methodology that most applications utilize. Some applications of the code do present an interface for other modules or applications to utilize in a shared manner. In such situations, however, the code is based on the reproduced device scan and/or the IOCTL request code.
One of the problems with these solutions is that such processes rely on the reproduction of the actual code that accomplishes the device scan and/or IOCTL request. Such techniques are error prone and must be copied into a new project, while ensuring compatibility with the new code. Additionally, the code must be integrated into the project's data structures. This process tends to introduce bugs, which must be fixed in each project.
The maintenance of the device scan and/or IOCTL request code, if not centralized, also presents a problem because many of the projects implemented do not utilize this particular portion of the code, which is fixed after the initial development is accomplished. Another issue inherent with current solutions is that it can take a very long time to produce a utility application because of the need to reproduce and copy the code. Aside from this basic work, many utility applications are relatively simple to implement. Finally, it is important to note that the worker code utilized implements certain and often repeated requests, which must be recreated in each project or may not be utilized at all, causing inefficient results.